home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Aug 89 / X0043-Re RespondsTo -Aug89 < prev    next >
Encoding:
Text File  |  1989-08-22  |  2.1 KB  |  50 lines  |  [TEXT/GEOL]
  1. Item    4260915                         11-Aug-89        23:29
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry,APL
  4.  
  5. To:     D1220                           Vari-Lite, Andy Meldrum,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re RespondsTo:
  10.  
  11. Andy,
  12.  
  13. I don't think it is technically possible to implement RespondsTo: in Object
  14. Pascal.  Each method that is defined has a unique ID, so if two totally
  15. unrelated classes define the Foo method those methods are different.
  16.  
  17. You mention that using Member is something that you are not supposed to do.  I
  18. think using RespondsTo: is equally unclean.  So if you feel that you need
  19. RespondsTo: then I would use Member instead.  (The reasons for avoiding Member
  20. is that it is too procedural and not very object-oriented.  Also, if you add
  21. new kinds of object later, you may need to modify the Member tests.)
  22.  
  23. As you said the simplest solution is to define every possible method in the
  24. common ancestor class and implement those methods in the appropriate classes.
  25.  
  26. You also mention a little about the user interface.  I think that you should
  27. disable commands that don't make sense given the current selection.  For
  28. example, the Set Intensity command should be disabled if none of the selected
  29. objects have an intensity.
  30.  
  31. Doing this requires a way to test the attributes that an object has.  You might
  32. do this using several methods that return a Boolean.  These can default to
  33. returning FALSE in the common class, but can be overridden in subclasses. Or
  34. you could have a series of Boolean fields that you can test.
  35.  
  36. If you have these fields, then you can test them to decide whether a given
  37. object has an intensity, for example.  This is better than using Member since
  38. you won't be assuming that a particular class has a particular attribute.
  39.  
  40. Larry Rosenstein
  41.  
  42.  
  43. P.S. It may be possible to come up with a better approach by thinking about the
  44. problem in a different way.  Without knowing more it is hard to offer advice,
  45. but an example would be to think about making attributes classes.  Perhaps an
  46. object in your program can have a list of attribute objects.
  47.  
  48.  
  49.  
  50.